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(g) Verfahren zur konsistenten Nachrichtenubertragung 

(g) Die Erftndung beaeht sich auf ein Verfahron zur Nachrich- 
tenubertragung zwischen TeHnehmorn In einom vortoilten 
System mit Token-Passing. Urn - auch im Stdrungsfall - eine 
konslstente Nachrichtenubertragung zu erzlelen, wlrd ein 
spezielles Token-Verfahren venwendet, das auf einer Ober- 
einstimmung des Oberwachungs- und Informationsstandes 
der Teilnohmer basrert und mIt dem Im FehlerfatI ain aus 
einer fortlaufenden Sequenznummar abgeleitetes folgarich- 
tiges \Ariederauf88tzen - ohne Beeintrachtlgung der Datan- 
konsistenz - durchgefuhrt wlrd. Das Verfahren ist In unter- 
schiedlichen Varianten realisierbar, namlich mit ringformlger 
Informationsfuhrung von Nutzdaten Oder der Obertragung 
von Nutzdaten Im physikaHschen Multicast und der ringfor- 
mlgen Fuhrung zugehoriger KontroHinformatlon. Das Ver- 
fahren kann In leittechntschen Aniagen eingesetzt werden. 
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Die ErHndung bezieht sich auf ein Verfahren zur 
NachrichtenQbertragung gem^B dem Oberbegriff des 
Anspruchs 1. 5 

Ein solches, nach dem Token-Passing-Prinzip arbei- 
tendes Verfahren ist beispielsweise aus H.-G. Gdhring, 
F,-J. Kauffels, Token-Ring: Grundlagen, Strategien, 
Perspektiven", DATACOM-Verlag Lipinski. 1990, ins- 
besondere Kapitel 2.4 bekannt. to 

Es existiert eine Reihe ringbasierter Protokolle» die 
nach dem sogenannten Token-Passing-Prinzip arbeiten 
und als Token- Protokolle bekannt sind. Sie wurden far 
verschiedene LAN-Bussysteme standardisiert 
(IEEE802.4/Token-Bus, IEEE80Z5/Token-Ring, ANSI js 
X3T9^/FDDI). Die Verfahren basieren auf einem To- 
ken, einem spezielien Bitmuster. das zur Bus-Zugriffs- 
steuerung verwendet wird. Das Token zirkuliert in ei- 
nem logischen bzw. physikalischen Ring, der zwischen 
den einzelnen Teilnehmem aufgebaut wird. 20 

Diese Protokolle gewahrleisten allerdings nicht die 
Datenkonsistenz in verteilten Systemen mit dezentraler 
Datenhaltung bei Fehlem bzw. Aus^llen von System- 
komponenten; d. h. bei Verwendung dieser Verfahren 
ist nicht sichergestellt, daB alle Teilnehmer nach Ausfai- 25 
len bzw. Rekonfigurationen infolge von Ausfallen glei- 
chen Informationsstand bezuglich ubertragener Nach- 
richten besitzen. Datenkonsistenz ist aber die dominan- 
te Anforderung an die betrachteten Systeme (vergL wei- 
tere Ausfuhrungen). Weiterhin erweisen sich die Proto- 30 
kolle bei Obertragung von Nachrichten geringer Lange 
als sehr ineffizient (Token-Ring: jede Nachricht muB 
eine vollstandige Token-Runde zurucklegen, bis die 
nachste Station senden darf; Token- Bus: Ubertragung 
und Bestatigung fur jede Nachricht und jeden Empfan- 35 
ger getrennt). In den betrachteten Systemen wird diesel- 
be Nachricht im allgemeinen an mehrere Empfanger 
Qbertragen (Multicast- Obertragung). Existierende To- 
ken- Protokolle ermoglichen nur eine unbestatigte Mul- 
ticast-Obertragunj^; bestatigte Obertragung ist nur im 40 
Unicast moglich (Ubertragung an nur einen Empfanger) 
und erfordert eine getrennte Bestatigungsphase. Neben 
diesen grundsatziichen Problemen sind weitere, proto- 
kollspezifische Nachteile vorhanden, beispielsweise 
Vertauschungen der Reihenfolge Qbertragencr Nach- 45 
richten bzw. die fehlende Unterstutzung von Bus-Re- 
dundanz. 

Diese bekannten ringbasierten Verfahren konnen 
nicht alle wesentlichen Anforderungen erfiillen, die sich 
bei einer Anwendung in industriellen Leitsystemen er- 50 
geben. 

Das aus der DE-C2-40 10 266 bekannte Verfahren zur 
gesicherten Informationsubertragung, beispielsweise in 
der Ausfuhrung des Ethernet Network/Broadcast To- 
ken Bus (EN/BTBX erfuilt die Anforderungen ebenfails 55 
nicht in vollem Umfang. Die Obertragung erfolgt gesi- 
chert, aber nicht konsistent So sind bei diesem Verfah- 
ren Vertauschungen der Reihenfolge sowie Duplikate 
von Nachrichten bei Ausfallen/Rekonfigurationen m5g- 
lich. S^mtliche Information wird im Broadcast ubertra- eo 
gen, dies fiihrt bei Verwendung moderner Rechnertech- 
nik zu einer relativ hohen Rechnerbelastung. EN/BTB 
erfordert programmierbare (intelligente) Kommunika- 
tions-ControlIer; moderne Rechner sind aber aus- 
schlieBlich mit nichtintelligenten Controltem ausgestat- 65 
tet EN/BTB unterstOtzt nicht die Verwendung standar- 
disierier Protokolle. 

Der typische Aufbau eines Leitsystems, sowie die An- 



forderungen an ein solches Leitsystem bzw. an ein darin 
benutztes Obertragungsverfahren wird nachstehend 
anhand von Hg. 1 eri&utert 

Fig. 1 zeigt schematisch den Aufbau eines Leitsy- 
stems. bestehend aus mehreren Rechnerkomponenten, 
wie Vorrechner (VR) zur ProzeBkopplung, Leitrechner 
(LR) zur Bearbeitung leittechnischer Grundfunktionen, 
die als SCADA-Funktionen bekannt sind, Bedienpiatz- 
rechner (BR) zur ProzeB-Visualisierimg und zusatzli- 
chen Rechnem zur Bearbeitung optionater Sekund3r* 
funktionen (SF). Die Rechner sind fiber ein Lokales 
Netzwerk (LAN), typischerweise Ethernet, gekoppelt 
Zur ErhOhung der VerfQgbarkeit des Gesamtsystems 
werden Rechner wichtiger Funktion (im Bild: VR und 
LR) sowie der LAN-Bus redundant ausgefahrt Die 
Rechner operieren auf einem jeweils lokal gehaltenen, 
fortlaufend aktualisierten ProzeBabbild (dezentrale Da- 
tenhaltung). Anderungsdaten werden als Nachrichten 
versandt Aufgrund der Verteilung bzw. Redundanz von 
Funktionen und DatenbestSnden ergeben sich komple- 
xe Datenflusse im verteilten System. 

Die wesentlichen Anforderungen an solche Leitsyste- 
me sind hohe Verfugbarkeit, kurze, garantierte Reak- 
tionszeiten sowie Konsistenz der verteilten Datenbe- 
stande. 

Datenkonsistenz ist Voraussetzung fOr den bestim- 
mungsgemaBen Betrieb der Leitsysteme. Sie ist trivial 
im fehlerfreien Fall, erfordert aber bei Ausfallen/Re- 
konfigurationen im System spezifische MaBnahmen zur 
nahtlosen Fortf iihrung des Nachrichtenaustauschs. Dar- 
aus resultieren sehr hohe Anforderungen an die Kom- 
munikation in verteilten Leitsystemen; sie umfassen: 

— Nachrichtenaustausch ohne Verlust, VerfSI- 
schung, Vervielfaltigung und Vertauschung von In- 
formation (Fuhrungskonsistenz), Vertauschung be- 
zieht sich dabei auf Nachrichten eines Absenders, 
die sogenannte FIFO-Reihenfolge. 

— Nachrichten an mehrere Empfanger mOssen an 
alle Empfanger oder an keinen ubertragen werden 
(Atomaritatsprinzip). 

— Obertragung von Nachrichten in jeweils identi- 
scher Reihenfolge an alle Empfanger (totale Rei- 
henfolge von Nachrichten). 

— Vermeidung von Oberholeffekten von Ur- 
sprungsinformation und abgeleiteter Information 
(kausale Reihenfolge von Nachrichten). 

— Schnelle, deterministische Obertragung von 
Nachrichten. 

— Schnelle Ausfalierkennung von Rechnem bzw. 
LAN-Bus durch standige gegenseitige Oberwa- 
chung. 

— Bei Ausfall von Rechnern automatische Ausglie- 
derung derselben aus dem Nachrichtenverkehr. 

— Bei Ausfall des LAN-Bus automatische Um- 
schaltung auf redundantes LAN. 

— Geringe LAN- und Rechner-Belastung durch 
System-Kommunikation. 

— Datenaustausch zwischen in Hard- und Softwa- 
re unterschiedlichen Rechnem. 

Datenkonsistenz umfaBt die vier erstgenannten An- 
forderungen an die Nachrichtenubertragung. Probleme 
bezOglich der Fuhrungskonsistenz entstehen durch 
Obertragungsfehler bzw. Ausfaile von Bus oder Emp- 
fanger. Das Atomaritatsprinzip wird durch den Ausfall 
der Informationsquelle selbst beeintrachtigt Eine Ver- 
tauschung von Nachrichten (totale und kausale Reihen- 
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folge) tritt auf bei indeterministischem Zeitverhalten im 
System, z. B. bei Rekonfigurationen bzw. Nachrichten- 
wiederholungen infolge von Ausfallen bzw. Obertra- 
gungsstarungen. 

In verteilten Rechnersystemen, insbesondere bei Ver- 5 
wendung des Betriebssystems UNIX, wird das Client/ 
Server- Konzept fOr den Datenaustausch verwendet 
Dieses Konzept ist auf eine zentralisierte Datenhaltung 
und auf Systeme ohne spezifische Echtzeitanforderun- 
gen zugeschnitten, es erfullt die obigen Anforderungen 30 
nicht Erforderlich ist die Kommunikation nach dem Er- 
zeugerA^erbraucher- Prinzip ( Produce r/Consumer- 
Prinzip). Die standardisierten TCP/IP-. UDP/IP- bzw. 
ISO/OSI-ProtokoIle sind auf das Client/Server- Kon- 
zept ausgerichtet, ihre Eigenschaften sind der beschrie- 15 
benen Aufgabenstellung nicht angemessen. Dennoch ist 
ihre Verwendung aus Kostengrunden sowie zur Kom- 
munikation zwischen Rechnern unterschiediichen Typs 
notwendig« 

Die herkommiiche Verwendung dieser Protokolie — 20 
mit Implementierung von Kommunikations-Verbindun- 
gen zwischen verteilten Prozessen entsprechend einer 
durch die Applikation vorgegebenen Struktur (logische 
Punkt-zu-Punkt-Verbindungen) - hat schwerwiegende 
Nachteile. Dies gilt insbesondere fur das vorherrschen- 25 
de. verbindungsorientierte TCP/IP-Protokoil bzw. in 
ahnlicher Weise auch fur ISO/OSI-ProtokoUe. Folgende 
Grunde lassen sich anfuhren: 

— Einzel-Obertragung von Nachrichten fiihrt bei 30 
Verwendung ublicher nichtintelligenter Kommuni- 
kations-ControIler zu hohem Obertragungsauf- 
wand (Kontext-Wechsel und ProtokoU-Bearbei- 
tung im Host). Zur Reduzierung der Rechner- und 
LAN-Last ist eine Sammelubertragung von Nach- 35 
richten mit kombinierter Zeit-/Mengensteuerung 
notwendig. 

— Die Informationsselektierung, d. h. die Auswahl 
der an die Empfanger zu Qbertragenden Nachrich- 
ten erfolgt bei standardisierten Protokollen sende- 40 
seitig. Der Sender fuhrt pro Empfanger eine Aktua- 
lisierungsliste, dies fiihrt zu zusatzlicher Rechner- 
belastung. 

— Standardisierte Protokolie erlauben nur gerich- 
let eine bestatigte Obertragung. Dies fuhrt bei den 45 
betrachteten Systemen zu einem Multiplikatoref- 
fekt fur Packen und Obertragen von Nachrichten: 
In grSBeren Leitsystemen wird jede Nachricht 
mehrfach gepackt und uber den Bus Obertragen. 
Bei redundant ausgefQhrtem Sender ist zusatziich 50 
zur Obertragung zu den Empfangern jede Verbin- 
dung getrennt mit dem Nebenrechner zu synchro- 
nisieren. 

— Eine automatische Oberwachung von Kommu- 
nikations-Verbindungen ist nicht Bestandteil der 55 
TCP-Spezifikation und somit nicht in jeder Proto- 
koll-Version vorhanden. Die Konfigurierung des 
Oberwachungszyklus (Defauit-Einstellung: 2 h) ist 
ebenfalls nicht f Or jede Protokoll- Version moglich. 

— Bei gegenseitiger Oberwachung der Rechner eo 
uber Verbindungsabbruch im Fehlerfall (Timeout) 
ist nicht fiir alle Protokoll-Versionen die Anpas- 
sung der Timer an die konkreten Zeitanforderun- 
gen mdglich. TCP/IP schreibt eine minimale Zeit- 
dauer von 100 s bis zu einem Verbindungsabbruch 65 
vor, die Einstellung kleinerer Werte ist nicht jstan- 
dard-konform. Als Ldsung zur gegenseitigen Ober- 
wachung bleibt nur ein zusatzlicher (redundanter) 
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Bestadgungsmechanismus auf Anwendungsebene 
mit entsprechendem Overhead. 

— Aufgrund der gerichteten Obertragung ergibt 
sich ein enormer Verbindungsaufwand im System. 
Jeder Rechner ist mit jedem anderen zu koppeln. 
Bei redundantem LAN-Bus sind Verbindungen 
uber beide Busse zu betreiben. Beispiel: Ein mittle- 
res Leitsystem, bestehend aus 8 Rechnern und re- 
dundantem LAN-Bus erfordert 2x8x7 « 112 
VoUduplex- bzw. 224 Halbduplexverbindungen. 

— Die Systemstruktur ist in die Software program- 
miert bzw. parametriert (Semantik: "Sende Nach- 
richt an', "Empfange Nachricht von*> Die Realisie- 
rung erweist sich als aufwendig, speziell die Fehler- 
verarbeitung. 

— Aufgrund der Strukturabhangigkeit der Softwa- 
re ergeben sich Ruckwirkungen im Fehlerfall durch 
das notwendige Producer/Consumer- Prinzip. 

— Standardisierte Protokolie gestatten bei Ausfall 
des LAN-Busses keine automatische Umschaltung 
auf einen redundanten Bus. 

— Ausfalle/Rekonfigurationen im System fQhren 
zum Datenverlust in den Protokollpuffem. Dies er- 
fordert die zusatzliche Pufferung der Sendedaten 
auf Appiikationsebene. 

— Datenkonsistenz erfordert mehrphasige Ober- 
tragungskonzepte. Diese sind aufwendig zu reali- 
sieren (hoher Zeit- und Nachrichtenaufwand) und 
erfordem die Steuerung der zeitlichen Abfolge der 
Obertragung. TCP-Empfangsbestatigungen kon- 
nen zur Realisierung von 2-Phasen-Konzepten 
nicht ausgewertet werden, es ist ein zusatzlicher 
Bestatigungsmechanismus auf Anwendungsebene 
notwendig. 

— Totale und kausale Reihenfolge von Nachrich- 
ten erfordert bei herkdmmlicher Verwendung stan- 
dardisierter Protokolie aufwendige MaBnahmen, 
beispi els weise Nachrichten-Historien. 

Standardisierte KommunikationsprotokoUe erfuUen 
also bei herkommlicher Verwendung die Anforderun- 
gen an Leitsysteme nicht 

Da von ausgehend liegt der Erfindung die Auf gab e 
zugrunde, ein Verfahren zur konsistenten Nachrichten- 
ubertragung anzugeben, das die vorgenannten Anforde- 
rungen erfullt, unter gleichzeitiger Anwendbarkeit stan- 
dardisierter Kommunikations-Protokolle. 

Diese Aufgabe wird bei einem Verfahren gemaB dem 
Oberbegriff des Anspruchs I durch dessen kennzeich- 
nende Merkmale geldsL 

Das erfindungsgemaSe Verfahren ist in insgesamt 
drei Grundvarianten realisierbar, namiich einem als er- 
ste Variante bezeichneten Ring- Multicast(R-MC)- Ver- 
fahren und einem als zweite Variante bezeichneten Da- 
tagramm-Multicast(D-MC)-Verfahren, das wiederum 
— je nach Zugriffsverfahren — in zwei Ausfuhrungen 
(D-MC/Z. D-MC/S) realisierbar ist 

Die Verfahrensvarianten — nachstehend auch kurz 
als Verfahren bezeichnet — enthalten teils unterschied- 
liche. teils ubereinstimmende Merkmale, wie im An- 
spruch 1 angegeben und auch unten beschrieben ist 

Beim Verfahren Ring- Multicast (R-MC) wird ein To- 
ken fur den Nachrichtentransport, zur Steuerung des 
Sendezugriffs sowie fur die gegenseitige Oberwachung 
der Rechner verwendet (Daten-Token). 

Beim Verfahren Datagramm- Multicast mit zugriffs- 
gesieuerter Nachrichtenubertragung (D-MC/Z) wird 
ein Token zur Steuerung des Sendezugriffs, zum Aus- 
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tausch von Bestatigungs- und Reihenfolgeinformation 
sowie zur gegenseitigen Oberwachung verwendet 
(Kontroll-Token). Die NachrichtenQbertragung selbst 
erfolgt bei Token-Besitz im physikalischen Broad- bzw. 
M ul ticas t mi t Datagrammen. 5 

Beim Verfahren Datagramm-Multicast mit spontaner 
NachrichtenQbertragung (D-MC/S)wird ein Token zum 
Austausch von BestStigungs- und Reihenfolgeinforma- 
tion sowie zur gegenseitigen Oberwachung verwendet 
(Kontroll-Token). Die Nachrichtenubertragung erfolgt lo 
spontan, unabhSngig von der Position des Token, im 
physikalischen Broad- bzw. Multicast mit Datagram- 
men. 

Die Verfahren D-MC/Z und D-MOS werden nach- 
folgend auch als Datagramm- Verfahren bzw. data- 15 
grammorientierte Verfahren bezeichnet. BestStigungs-, 
Reihenfolge- und Statusinformation werden nachfol- 
gend unter dem Begriff KontroUinformation zusam- 
mengefaBt 

Beim Verfahren Ring-Multicast (R-MC) handelt es 20 
sich um ein logisches Multicast-Konzept Die data- 
grammorientierten Verfahren (D-MC) lassen sich so- 
wohl im physikalischen Multi- als auch im Broadcast 
realisieren. Im folgenden wird zwischen Multi- und Bro- 
adcast nicht weiter unterschieden, es wird der allgemei- 25 
nere Begriff des Multicast verwendet. 

Vorteilhafte Ausgestahungen der Verfahren ergeben 
sich aus Unteranspruchen und der nachstehenden Be- 
schreibung der Erfmdung. 

Die Verfahrensvarianten sind in ihrem Grundaufbau 30 
ahnlich und insofem gleichwertig, als jedes der Verfah- 
ren alle Anforderungen an den Nachrichtentransport 
ohne Einschrankung erfullt Daruber hinaus besitzt je- 
des der Verfahren charakteristische Eigenschaften im 
Vergleich mit den anderen. Diese Merkmale kommen 35 
bei einer Verfahrens-Realisierung. d. h. unter konkreten 
Randbedingungen zum tragen; sie werden bei der nach- 
stehenden Verfahrensbeschreibung erlautert. Die erfin- 
dungsgemaBen Verfahren sind an keinen Standard ge- 
bunden. Eine vorteilhafte Ausgestaltung ist auf der Basis 40 
standardisierter LAN-Bussysteme und Kommunika- 
tions-ProtokoIle mdglich. Bereits vorhandene Teilfunk- 
tionen konnen genutzt werden, beispielsweise CRC- 
Prufsumme standardisierter ProtokoIIe bzw. Kollisions- 
erkennung mit automatischer Wiederholung bei Ver- 45 
wendung eines Ethernet-LAN (IEEE8023). Standardi- 
sierte ProtokoIIe werden in einer problemspezifischen 
Weise verwendet. Dies gestattet es, die Anforderungen 
an Leitsysteme zu erfullen und die prinzipiellen Vorzu- 
ge standardisierter ProtokoIIe zu nutzen. unter Vermei- 50 
dung der erlauterten Problempunkte. Eine Realisierung 
auf der Basis standardisierter ProtokoIIe wird nachfoU 
gend an einem Ausfiihrungsbeispiel erlautert. 

Das Verfahren Ring- Multicast (R-MC) ist ein reines 
Ringkonzept. Das Token dient der Nachrichtenubertra- 55 
gung, der Steuerung des Bus-Zugriffs, der Sequentiali- 
sierung der Nachrichten-Reihenfolge sowie der gegen- 
seitigen Oberwachung. Die Tokenlange wird dynamisch 
dem aktueilen Nachrichtenaufkommen angepaBt Die 
Obertragung des Token kann unbestStigt erfolgen. da eo 
jeder Teilnehmer durch Oberwachung des nachsten To- 
kenempfangs den Umiauf des Token kontroUieren kann 
(impliziter BestStigungsmechanismus im Ring). Das 
Verfahren Ring-Multicast ist zugeschnitten auf kleine 
und mittlere Leitsysteme. Gem&B einer vorteilhaften es 
Ausgestaltung sind Nachrichten auch blockweise im To- 
ken Qbertragbar. 

Bei den datagrammorientierten Verfahren (D-MC) 



werden Nachrichten im physikalischen Multicast uber- 
tragen. GemaB einer vorteilhaften Ausgestaltung wer- 
den Nachrichten in Blocken zusammengefaBt und als 
Datagramme Qbertragen. Die Datagramm- Obertra- 
gung selbst erfolgt unbestHtigt Das Token dient der 
Obertragung von KontroUinformation, d h. von Bestati- 
gungen und Reihenfolgeinformation zu den ubertrage- 
nen Nachrichtenblocken, sowie der gegenseitigen 
Oberwachung. Ober den Kontroll-Token wird eine be- 
statigte Obertragung der Nachrichtenblocke implemen- 
tiert. es kommt ein Mechanismus mit negativer BestSti- 
gung zur Anwendung: Obertragene Nachrichtenbldcke 
werden vom Absender im Token als gesendet markiert, 
die weiteren Teilnehmer prufen den Erhalt der Nach- 
richtenblocke und tragen bei Nichterhalt eine negative 
Bestatigung im Token ein. In diesem Falle muB der Ab- 
sender die Obertragung wiederholen. 

Beim zugriffsgesteuerten Verfahren (D-MCVZ) wird 
auch die Sendeberechtigung im Token weitergereichL 
Beim Verfahren mit spontaner Obertragung (D-MC/S) 
sind alle Stationen jederzeit sendeberechtigt, unabhSn- 
gig von der aktueilen Position des Kontroll-Token. 

Die Datagramm- Verfahren sind auf groBe Leitsyste- 
me mit hohem Datenaufkommen ausgerichtet Auf- 
grund der Obertragung im physikalischen Multicast er- 
gibt sich im Vergleich zum Ring-Multicast-Konzept 
(R-MC) eine Minderung der Sende- imd Buslast. Der 
Token umfaBt nur KontroUinformation. d. h, die Ulnge 
und die Umlaufzeit werden reduzierL Weiterhin ist in 
den betrachteten Systemen die Kommunikationslast 
stark asymmetrisch. Alle Prozefidaten werden fiber den 
Leitrechner gefiihrt und von diesem an die weiteren 
Rechner Qbertragen. Die datagrammorientierten Ver- 
fahren sind an diese Belastungssituationen angepaBt. 
Nur Teilnehmer mit vorhandenen Sendedaten fuhren 
eine Multicast-Obertragung durch. Bei sehr hohem Da- 
tenaufkommen sind beim Verfahren mit spontaner 
Obertragung (D-MC/S) mehrere Datagramm-Obertra- 
gungen wahrend eines Tokenumlaufs moglich. 

Alle drei Alternativen gewahrleisten die Datenkonsi- 
stenz bei Fehlem im verteilten System. Diese Eigen- 
schaft beruht auf der Obereinstimmung der Token- Posi- 
tion mit dem Obertragungsstand von Nachrichten im 
System. Beim Verfahren Ring-Multicast wird der Ober- 
tragungsstand von Nachrichten unmittelbar durch den 
Token widergespiegelt Bei den datagrammorientierten 
Verfahren wird der Obertragungsstand durch die im 
Token gefuhrte KontroUinformation Qbertragener 
Nachrichten(-bl6cke) wiedergegeben: Obertragene 
NachrichtenblScke werden vom Sender bei Token- Er- 
halt mit ihrer Kennung im Token eingetragen. vom 
Empfanger erst bei Token-Erhalt uber diese Kennung 
freigegeben, d. h. auch bei diesem Verfahren spiegelt 
das Token den aktueilen Obertragungsstand wider. 

Im Token ist eine fortlaufende, von jedem Absender 
inkrementierte Sequenznummer eingetragen. Das To- 
ken dient der Fehlererkennung und -lokalisierung. Auf- 
grund der Obereinstimmung von Token- Position und 
Ubertragungszustand laBt sich im Fehlerfall uber die 
Ermittlung der letztgultigen Token- Position auch der 
aktuelle Obertragungsstand der einzelnen Teilnehmer 
exakt rekonstruieren. Dies ermoglicht die nahtlose 
Fortfuhrung der Obertragung unter Wahrung der Fuh- 
rungskonsistenz. Das Atomaritatsprinzip ist aufgrund 
der ringformigen Obertragung von Nutz- bzw. Kon- 
trolldaten. d. h. der Obertragung an jeweils nur einen 
Empfanger grundsatzlich erfullt. Aufgrund des Seriali- 
sierungseffekts des Token bezuglich Qbertragener 
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Nachrichten (R-MC) bzw. der Kontrollinformation 
ubertragener Nachrichtenblocke (D-MC) erfolgt die 
Nachrichtenflbertragung mit FIFO-Reihenfolge, totaler 
und kausaler Reihenfolge. 

Defekte Teilnehmer werden automatisch ausgegUe- 
dert, der Nachrichtentransport erfolgt auf Anwen- 
dungsebene auch im Fehlerfall riickwirkungsf reL In wei- 
terer Ausgestaltung kann eine automatische Busum- 
schaltung bei St6rungen im Kommunikationssystem un- 
ter Wahrung der Datenkonsistenz vorgesehen werden. 
Vorteilhafte Ausgestaltungen der FehlertoleranzmaB- 
nahmen werden anhand eines Ausfuhrungsbcispiels er- 
ISutert 

Durch die Verwendung eines Token- Protokolls besit- 
zen die Verfahren ein stabiles und berechenbares Zeit- 
verhalten. Dies gilt auch fOr das Verfahren D-MC/S, 
welches koUisionsbehaftet arbeitet Die Anzahl der Sen- 
devorgSnge pro Tokenumlauf wird bei diesem Verfah- 
ren begrenzt, beispielsweise auf 20% der maximalen 
Belastung bei Ausfuhrung des Verfahrens auf der Basis 
eines Ethernet- LAN, Nennenswerte Verzogerungen 
durch Kollisionen werden hierdurch vermieden. 

Die erfindungsgemaUen Verfahren ermdglichen eine 
bestatigte Multicast-Obertragung. Dies, sowie die Ver- 
wendung eines kombinierten Verfahrens zur gegenseiti- 
gen Oberwachung und zum Austausch von Nachrich- 
ten, Bestatigungen und Reihenfolgeinformation sowie 
der blockweisen Obertragung von Nachrichten fflhrt zu 
einer deutlichen Reduzierung der LAN- und Rechner- 
belastung, der Protokoll-Komplexitat und des Realisie- 
rungsaufwands im Vergleich zu bestehenden Konzep- 
ten. 

Die drei erfindungsgemaBen Verfahren werden nach- 
stehend anhand von AusfQhrungsbeispielen nSher er- 
l&uterL 

Ausftihrungsbeispiele zu den Verfahren 



ubertragen, die Blockubertragung arbeitet atoman Bei 
fehlerhafter Obertragung bzw. Verlust von Block- Frag- 
menten wird ein Informationsblock vollstandig verwor- 
fen. 

5 Die nachfolgende Beschreibung erfolgt getrennt fur 
das Ring- Multicast- Verfahren sowie fur die Data- 
gramm- Verfahren, Letztere sind ahniich aufgebaut, sie 
werden gemeinsam erlautert, auf Unterschiede wird an 
jeweiliger Stelle hingewiesen. 
10 Es wird auf nachstehende Zeichnungsfiguren bezug 
genommen: 
Fig. 1 Aufbau eines Leitsystems, 
Fig. 2A bis 2F Obertragungsablauf beim Ring-Multi- 
cast(R-MC)- Verfahren, 
15 Fig. 3 Daten-Token-Aufbau bei R-MC 

Fig. 4A bis 4F Obertragungsablauf beim datagramm- 
orientierten Verfahren mit zugriffsgesteuerter Obertra- 
gung (D-MOZ), 
Fig. 5A bis 5F Obertragungsablauf beim datagramm- 
20 orientierten Verfahren mit spontaner Obertragung 
(D-MC/S), 

Fig. 6 Kontroll-Token-Aufbau bei D-MQ 
Fig. 7 Nachrichtenblock-Aufbau bei D-MC 
Die Eriauterung der AusfOhrungsbeispiele ist jeweils 
25 gegliedert in eine Beschreibung des zeitlichen Ablaufs, 
Eriauterungen der Protokoli-Eigenschaften sowie eine 
Beschreibung der ausgetauschten Informationseinhei- 
ten. Die grundsStzliche Beschreibung erfolgt f tlr ein ver- 
teiltes System, bestehend aus drei Teilnehmern 
30 (Tl — T3). Der zeitliche Ablauf ist in mehreren Phasen 
dargestellt(A— F> 

1. Ring-Multicast (R-MC) 



35 



Die Ausfuhrungsbeispiele wurden als Kommunika- 
tionssysteme in einem verteilten Rechnersystem imple- 40 
mentiert. Die Systeme basieren auf dem standardisier- 
ten UDP/IP-ProtokolL UDP/IP arbeitet verbindungs- 
los, es ermdglicht eine unbestatigte Obertragung von 
Datagrammen im Uni-, Multi- und Broadcast. Als Bussy- 
stem wird ein Ethernet-LAN (IEEE8023) verwendet 45 
Die zugrunde gelegte standardisierte Hard- und Soft- 
ware umfaBt automatische SicherungsmaQnahmen ge- 
gen Datenverfalschung (CRC-Prufsumme) sowie zur 
KoUisionsbearbeitung. Bei erkannten Kollisionen er- 
folgt eine automatische Frame- Wiederholung. Aus die- 50 
sen Grunden werden Kollisionen bzw. Fehler durch ver- 
falschte Daten nachstehend nicht wciter beracksichtigt. 

Die ausgetauschten Informationseinheiten weisen ab- 
hangig vom Datenaufkommen stark unterschiediiche 
Langen auf (im Bereich von 10 Byte bis 30 kByte). Gro- 55 
Be Informationseinheiten werden von den darunterlie- 
genden Netzwerk- und Protokollschiditen fragmen- 
tiert, d h. in kleinere zu ubertragende Einheiten aufge- 
teilt. Jedes Fragment wird mit protokollspeafischer In- 
formation erweitert Um einen einheitlichen, von der eo 
Lilnge der Informationseinheiten und von den unterla- 
gerten ProtokoU- und Netzwerkschichten unabhSlngi- 
gen Obertragungs-Mechanismus zu schaffen. sowie zur 
Behandlung des Verlusts einzelner Fragmente groBercr 
Informationseinheiten, wurde im Rahmen einer vorteil- es 
haften Ausgestaltung ein blockorientierter Obertra- 
gungs-Mechanismus realisierL Die ausgetauschten In- 
formationen werden als zusammenhSngende BIdcke 



1.1 Beschreibung 

Die Fig. 2A bis 2F zeigen den zeitlichen Ablauf der 
OberU-agung im fehlerfreien Fall fur das Verfahren 
Ring-Multicast (R-MC). Ausgangszustand sei die Zirku- 
iation eines leeren Daten-Token T (Fig. 2A). Teilnehmer 
Tl besitzt zu ubertragende Nachrichten Nl, er trSgt 
diese bei Tokenerhalt im Token ein und reicht den To- 
ken T an den Nachfolger T2 weiter (Fig. 2B). Der Nach- 
folger T2 halt Nachrichten N2 zur Obertragung bereit. 
Er kopiert bei Erhalt des Token T dessen Inhalt in einen 
lokalen Empfangspuffer. fQgt die eigenen Sendedaten 
N2 am Tokenende an und reicht den Token weiter 
(Fig. 2C). Nach der Weitergabe des Token werden aus 
der lokalen Kopie des Token Nachrichten fur die An- 
wendung selektiert (im Beispiel die Nachrichten Nl des 
Teilnehmers Tl). Fur Teilnehmer T3 ist die Vorgehens- 
weise analog zu T2 (Fig. 2D). Nach einem vollstftndigen 
Umlauf des Token T loscht Teilnehmer Tl die eigenen 
Nachrichten Nl aus dem Token, kopiert den Tokenin- 
hait in den lokalen Empfangspuffer, fugt neue Daten N 1 ' 
am Tokenende an, reicht den Token an Teilnehmer T2 
weiter und selektiert Nachrichten anderer Teilnehmer 
(Fig. 2E). Teilnehmer T2 bearbeitet den Token T analog 
zu Teilnehmer Tl, im Beispiel hat er keine weiteren 
Nachrichten zu versenden (Rg. 2F). 

Jeder Teilnehmer kann bei Tokenbesitz Nachrichten 
beliebiger Anzahl und LSnge im Token cintragen (varia- 
ble TokenlSnge). 

1.2 Verfahrensabergreifende Eigenschaften (alle drei 
Konzepte) 

Anhand des Konzepts Ring- Multicast lassen sich eini- 
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ge verfahrensubergreifende Eigenschaften eriautem, 
die auch fur die nachfolgend eriauterten Datagramm- 
Konzepte geiten: 

— Ein Ring-Aufbau kann von jedem Teilnehmer 
initiiert werden. 

— Stationen mussen zunachst in den Ring inte- 
griert werden, um am Nachrichtenaustausch teil- 
nehmen zu kdnnen. Hierzu ist eine Anmeldung der 
neu aufzunehmenden Station beim Vorgfinger not- 
wendig. 

— Die Obertragung alJer Informationseinheiten er- 
folgt blockorientiert 

— Das Token wird an alle Teilnehmer mit gleicher 
Haufigkeit gesendet, d. h. es existiert keine hohere 
Priorisierung fur bestimmte Teilnehmer. 

— Information zur Analyse der ZustSnde von 
Nachfolger und LAN-Bus wird asynchron zum To- 
ken ubertragen. 

— Information zur Neuaufnahme eines TeUneh- 
mers wird asynchron zum Token ubertragen. 

— Jede Station Qberwacht ihren Nachfolger, def ek- 
te Stationen werden vom Vorgtnger ausgegUedert 
Die Rekonfiguration erfolgtohne Beeintrachtigung 
der Datenkonsistenz. 

— Bel Busausfall erfolgt eine automatische Um- 
schaltung auf den redundanten Bus. Die Rekonfigu- 
ration erfolgt ohne Beeintrachtigung der Daten- 
konsistenz. 

13 Protokoll-Eigenschaften: R-MC 

— Vergleiche "Verfahrensubergreifende Eigen- 
schaften". 

— Nutzdaten werden ringfSrmig im System ge- 
fuhrt(gerichtete Obertragung des Daten-Token]^ 

— Das Daten-Token besitzt variable Lange. 

— Jeder Teilnehmer darf bei Token-Erhalt eigene 
Nachrichten im Token eintragen. 

— Es gibt keine ausgewahlte Station im System, 
wahrend der Rekonfigurationsphase wird die Sta- 
tion mit dem zuletzt gultigen Daten-Token tempo- 
rar zum Ringmaster. 

— Kollisionsfreier Datenverkehr im Normalbe- 
trieb. 

— Empfangsdaten werden nach der Token-Weiter- 
gabe selektiert und freigegeben. 

1.4 Ausgetauschte Informationseinheiten 

Zusatzlich zum bereits eriauterten Daten-Token wer- 
den noch weitere Informationseinheiten benutzt, die zur 
Fehlerbehandlung und zur Eingliederung neuer Teil- 
nehmer benotigt werden, wie weiter unten noch naher 
erlautert wird Die Informationseinheiten sind nachste- 
hend aufgelistet 

Daten-Token 

Enthalt die zu ubertragenden Nachrichten, geordnet 
nach den einzelnen Teilnehmem im Ring. 

Linkcheck- Request 

Anfrage eines Ringteilnehmers an seinen Nachfolger 
zur Teilnehmer- und Busuberwachung. 



Linkcheck-Acknowledge 

Antwort eines Ringteilnehmers auf einen Linkcheck- 
Request 

5 

Init-Token 

Enthalt die System-Statusinformation und die Se- 
quenznummer des Absenders. Der Absender teilt sei- 
10 nem Nachfolger die lokale System-Statusinformation 
mit und bewirbt sich gleichzeitig als Ringmaster. 

Konfigurations-Token 

15 Enthalt die System-Statusinformation und die Se- 
quenznummer des Ringmasters. Der Ringmaster teilt 
den weiteren Ringteilnehmern eine geanderte Ringkon- 
figuration mit (nach Neuaufnahme eines Teilnehmers 
bzw. Ausfailen). 

20 

Enter-Request 

Teilnehmer will Ring initialisieren oder als Ringteil- 
nehmer aufgenommen werden. Information wird vom 
25 aufnahmewilligen Teilnehmer an den gewunschten Vor- 
ganger geschickt 

Leave-Token 

30 Teilnehmer teilt den anderen mit, da8 er den Ring 
verlassen mdchte. 

Alle Informationen werden unbestatigt ubertragen. 
Token-Information wird im Ring an alien Teilnehmern 
vorbeigefiihrt. Die weiteren Informationseinheiten wer- 
35 den zwischen jeweils zwei Teilnehmem ausgetauscht, 
die Obertragung erfolgt asynchron zum Token. 

15Blockaufbau 

40 Fig- 3 zeigt beispielhaft den Aufbau des Daten-Token 
far das Verfahren Ring-Multicast (R-MC). Dem Header 
entsprechend dem erfmdungsgemaBen Verfahren mit 
Angaben zur TokenlSnge, der Block-Sequenznummer 
des Token und zum Blocktyp (hier: Daten-Token) fol- 
45 gen die Datenbereiche der einzelnen Ringteilnehmer, 
jeweils mit variabler LSnge. Jeder Datenbereich umfaBt 
einen teilnehmerbezogenen Header mit der Angabe des 
Teilnehmers und der Datenbereichslange und nachfol- 
gend die Nachrichten dieses Teilnehmers. Die Nachrich- 
50 ten bestehen wiederum aus einem Header und den Da- 
ten selbsL Der Nachrichten-Header setzt sich zusam- 
men aus einem Selektor zur Zuordnung von Nachrich- 
ten und der Angabe der Nachrichtenlange. 

Die in Fig. 3 in den Datenbereichen eingetragenen 
55 Teilnehmerbezeichnungen IC, KH-l, usw. bis K-1 sind 
so zu verstehen, daB K ein beliebiger Teilnehmer. z. B. 
Teilnehmer T2 (vergl. Fig.2A— 2F) sein kann. wobei 
dann der Teilnehmer K-l-1 der Teilnehmer T3 ist. und 
Teilnehmer K - 1 der Teilnehmer Tl ist Im Daten-To- 
60 ken stehen somit in diesem Beispiel an letzter Stelle die 
Daten des Teilnehmers Tl. 

Nicht eingezeichnet sind durch unterlagerte Proto- 
koll- und Netzwerkschichten hinzugefugte Informatio- 
nen (bei Fragmentierung teilweise mehrfach): Ethernet-, 
65 IP- und UDP-Header. 

Samtliche Informationseinheiten werden blockorien- 
tiert zwischen den Protokoll-Schichten ausgetauscht 
Init- und Konfigurations-Token beinhalten im Daten- 
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teil die System-Statusinformatioa Bei den asynchronen die Verarbeitung freigegeben (Fig. 4E). Wurde ein im 

Informationseinheiten steht im Datenbereich die Ken- KontroU-Token als ubertragen markierter Nachnchten- 

nungdesAbsendersb2w.derDatenbereichistleer.dh. block nicht empfangen, so wird im Kontrollfeld des 

es wird nur der Blockheader Qbertragen. Nachrichtenblocks eine negative Bestatigung emgetra- 

5 gen, der Absender muB die Ubertragung emeut durch- 

2.Datagramm-Mukicast(D-MC/ZiindD-MC/S) fahren. Zusatzlich pnift der Besitzer des Kontroll-To- 

ken. ob eigene Sendedaten des letzten Token-Zyklus 

Bei den datagrammorientierten Verfahren (D-MC) von alien Teilnehmem empfangen wurden. Wenn ja, 

erfolgt die Daten-Ubertragung im physikalischen Multi- wird der Datenblock im Sendepuffer sowie der Emtrag 

cast mit den Datagramm-Diensten des UDP/lP-Proto- lo im KontroU-Token geloscht Wenn nein (negative Be- 

koUs. Moderne Betriebssysteme ermSgiichen neben der statigung im Kontrollfeld). wird die Ubertragung mit 

Obertragung im physikalischen Multicast auch die Se- der alten Sequenznummer erneut durchgef uhrt Die glo- 

lektierung empfangener Frames durch Hardware-Me- bale Sequenznummer wird ebenfalls beibehalten. Dies 

chanismen. «t notwendig. um auf Empfangsseite Duplikate zu er- 

Die Datagramm-Obertragung erfolgt blockorientiert 15 kennen und nachgelieferte Nachrichtenbldcke mit kor- 

und unbestStigt, Zur Realisierung einer gesicherten rekter Reihenfolge fflr die Anwendung freizugebea 

Obertragung, der Definition einer einheitlichen Emp- Die Abfolge der Verarbeitung erfolgt far den Teil- 

fangsreihenfolge sowie zur gegenseitigen Oberwa- nehmer T3 sowie wShrend weiterer UmlSufe analog zur 

Chung wird ein Kontroll-Ring zwischen den einzelnen obigen Beschreibung (Fig. 4F). 

Kommunikations-TeiinehmemaufgebautBeimVerfah- 20 Die Zuordnung einer globalen Sequenznummer zu 

ren Daiagramm-Muhicast mit zugriffsgesteuerter Nachrichtenblocken und deren Vergabe fiber den To- 

Obertragung (D-MC/Z) erfolgt die Multicast-Obertra- ken garantiert die totaJe Reihenfolge der Nachrichten- 

gung von Nutzdaten nur bei Besitz des KontroII-To- bl6cke und der darin enthaltenen Nachrichten. Die kau- 

kens. Beim Verfahren mit spontaner Ubertragung sale Reihenfolge von Bldcken und Nachrichten ergibt 

(D-MC/S) erfolgen Nutzdaten-Obertragung und Aus- 25 sich ebenfalls aus der ringformigen Obertragung der 

tausch des Kontroll -Token asynchron, d h. die Obertra- Kontrollinformation (Sequentialisierungseffekt). 

gung eines Nachrichtenblocks ist zu jedem Zeitpunkt Die Fig. 5A bis 5F zeigen den zeitlichen Abiauf der 

moglich- Obertragung beim Verfahren mit spontaner Obertra- 

Ein Nachrichtenblock kann Nachrichten beliebiger gung (D-MC/S). Sendewillige Teihiehmer, im Bild T2. 

Anzahl und Lange beinhalten. 30 senden ihre Nachrichten N2 spontan im Multicast, asyn- 
chron zum zirkulierenden KontroU-Token (Fig. 5A, B). 

2.1 Beschreibung der Verfahren Bei Erhalt des Kontroll-Token tragt Teilnehmer T2 die 

KontroU-Information K2 des ubertragenen Nachrich- 

Der zeitliche Abiauf der Obertragung fur das data- tenblocks N2 in ein Kontrollfeld im Token ein (Fig. 5C). 

grammorientierte Verfahren mit zugriffsgesteuerter 35 Der Aufbau und die Abfolge der Bearbeitung empfan- 

Ubertragung (D-MC/Z) ist in den Fig. 4A bis 4F darge- gener Nachrichtenbl6cke und des Kontroll-Token ist 

stellt. Ausgangszustand sei die Zirkulation eines leeren identisch mit dem Verfahren mit zugriffsgesteuerter 

Kontroll-Token T. Teilnehmer Tl besitzt zu Obertra- Obertragung (D-MC/Z). Nach erfolgter Token-Bear- 

gende Nachrichten Nl (Fig. 4 A). Er fuhrt bei Tokener- beitung wird dieses an den Nachfolger T3 weiterge- 

halt die Datagramm-Obertragung im Multicast durch 40 reicht Weitere asynchrone Obertragungen von Nach- 

und tragt die Kontroil-Information Kl des ilbertrage- richtenbldcken durch beliebige Teilnehmer sind zu je- 

nen Nachrichtenblocks in ein Kontrollfeld im Token ein dem Zeitpunkt moglich (Fig. 5C). 

(Fig. 4B), Das Kontrollfeld umfaSt die Kennung des Ab- Die Freigabe empfangener Nachrichtenblocke er- 
senders, eine senderbezogene Sequenznummer sowie folgi wie beim zugriffsgesteuerten Verfahren bei To- 
eine globale Sequenznummer, welche den Nachrichten- 45 ken-Besitz (Fig. 5D, E, F). Die Mechanismen zur Steue- 
bl6cken zugeordnet wird. Das Token fuhrt hierzu eine rung der Nachrichten- Reihenfolge sind ebenfalls iden- 
globale Sequenznummer mit sich. Diese wird vom je- tisch mit denen des zugriffsgesteuerten Verfahrens. 
weiligen Token- Besitzer fUr jeden gesendeten Nach- 
richtenblock erhoht, der senderbezogenen Sequenz- 2.2 Protokoll-Eigenschaften: D-MC/Z 
nummer zugeordnet und gemeinsam mit dieser im Kon- 50 

trollfeld eingetragen. Ober die Zuordnung der globalen — Vergleiche *Verfahrensflbcrgreifende Eigen- 

Sequenznummer werden alle Nachrichtenbl6cke mit ei- schaften". 

ner eindeutigen und fortlaufenden Kennung versehen. — Kontrollinformation wird ringformig im System 

Diese Kennung gestattet eine einheitliche Empfangsrei- geftihrt (gerichtete Obertragung des Kontroll-To- 

henfolge fibertragener NachrichtenblCcke. 55 ken). 

AnschlieBend wird das Token an den Nachfolger T2 — Das KontroU-Token besitzt variable Lange. 

weitergereicht(Fig.4C).DieEmpfangerstationenbeIas- — Die Sendeberechtigung wird tiber den Token 

sen empfangene Nachrichtenblocke zunachst in den gesteuert. J eder Teilnehmer darf bei Token- Erhalt 

Empfangspuffern. ohne diese fur die Anwendung freizu- eigene Nachrichtenblocke als Datagramme ver- 

geben. Der Nachfolger T2 halt ebenfalls Nachrichten eo schicken imd diese im Token ein tragen. 

N2 zur Obertragung bereit. er ubertragt diese bei To- — Es gibt keine ausgewihlte Station im System, 

kenerhalt im Multicast (Fig. 4D) und tragt im Token die wahrend der Rekonfigurationsphase wird die Sta- 

Kennung K2 des Nachrichtenblocks N2 im Kontrollfeld tion mit dem zuletzt gultigen Kontroll-Token tem- 

ein. AnschlieBend uberpriift er, ob im Kontroll-Token porar zum Ringmaster. 

als Qbertragen markierte Nachrichtenblocke (Kl) im 65 - Kollisionsfreier Datenverkehr im Normalbe- 

Empfangspuffer vorhanden sind. Ist dies der Fall, so trieb. 

werden empfangene Nachrichtenblficke (Nl) entspre- — Wahrend des letzten Tokenumlaufs empfangene 

chend der globalen Sequenznununer geordnet und ffir DatenblQcke werden bei Tokenerhalt sortiert und 
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an die Anwendung freigegeben. 

— Daten werden im Broadcast bzw. Multicast 
ubertragen» 

— Bestatigungen, Reihenfolge-Information, Sy- 
stem-Zustandsinformation und Bus-Zugriffsverga- 
be werden im Token gef uhrt 

— Die Empfangs-Bestatigung erfolgt blockweise. 
Dies ist moglich. da durch die Mechanismen der 
Blockubertragung gewahrleistet ist, daB Informa- 
tionseinheiten beliebiger LSnge nur voUst^ndig 
Qbertragen werden (bei Veriust einzelner Frag- 
mente werden Bldcke komplett verworfen). 

23 ProtokoU-Eigenschaften: D-MC/S 

— Vergleiche '^erfahrensubergreifende Eigen- 
schaften" 

— KontroUinformation wird ringfdnmig im System 
gefUhrt (gerichtete Obertragung des Token), 

— Das KontroU-Token besitzt variable LSnge. 

— AUe Stationen sind zur Obertragung von Nutz- 
daten (Datagrammen) jederzeit sendeberechtigt 
Bei Token-Erlialt werden im letzten Tokenzyklus 
verschickte Nachrichtenbldcke im Token eingetra- 
gen. 

— Es gibt keine ausgewahlte Station im System, 
w£Lhrend der Rekonfigurationsphase wird die Sta- 
tion mit dem ztiletzt gUItigen Kontroll-Token tern- 
porar zum Ringmaster. 

— Wahrend des letzten Tokenumlaufs empfangene 
Datenblocke werden bei Tokenerhalt sortiert und 
an die Anwendung freigegeben. 

— Daten werden im Broadcast bzw. Multicast 
Qbertragen. 

— BestStigungen, Reihenfolge-Information und Sy- 
stem-Zustandsinformation werden im Token ge- 
fuhrt 

~ Wahrend eines Tokenumlaufs sind mehrere 
Obertragungen von Datenblocken moglich. 

— Die Empfangs-Bestatigung erfolgt blockweise. 
Dies ist moglich, da durch die Mechanismen der 
BlockObertragung gewahrleistet ist, daB Informa- 
tionseinheiten beliebiger Lange nur vollstandig 
ubertragen werden (bei Veriust einzelner Frag- 
mente werden Bldcke komplett verworfen). 

2.4 Ausgetauschte Informationseinheiten (D-MC/Z und 
D-MC/S) 

Zusatzlich zum bereits erlauterten Nachrichtenblock 
(Datagramm) und Kontroll-Token werden noch weitere 
Informationseinheiten benutzt, die zur Fehlerbehand- 
lung und zur Eingliederung neuer Teilnehmer benotigt 
werden, wie weiter unten noch naher erlautert wird. Die 
Informationseinheiten sind nachstehend aufgelistet Die 
ausgetauschte Information ist far beide Datagramm- 
Verfahren identisch. 

Nachrichtenblock 

Enthait die zu ubertragenden Nachrichten eines 
Ring-Teilnehmers. 

KontroU-Token 

Enthalt die Kontrollinformationen, (Bestatigungs-, 
Reihenfolge- und Statusinformation), geordnet nach 
den einzeinen Teilnehmern im Ring. 
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Linkcheck-Request 

Anfrage eines Ringteilnehmers an seinen Nachfolger 
zur Teilnehmer- und BusQberwachung. 

Linkcheck-Acknowledge 

Antwort eines Ringteilnehmers auf einen Linkcheck- 
Request 

Init-Token 



Enthalt die System-Statusinformation und die Se- 
quenznummer des Absenders. Der Absender teilt sel- 
ls nem Nachfolger die lokale System-Statusinformation 
mit und bewirbt sich gleichzeitig ais Ringmaster. 

KonHgurations-Token 

20 Enthalt die System-Statusinformation und die Se- 
quenznummer des Ringmasters. Der Ringmaster teilt 
den weiteren Ringteilnehmem eine geanderte Ringkon- 
figuration mit (nach Neuaufnahme eines Teilnehmers 
bzw. AusfallenX 

25 

Enter-Request 

Teilnehmer will Ring initialisieren oder als Ringteil- 
nehmer aufgenonunen werdea Information wird vom 
30 aufnahmewilligen Teilnehmer an den gewunschten Vor- 
ganger geschickt. 

Leave-Token 

35 Teilnehmer teilt den anderen mit, daB er den Ring 
verlassen mdchte. 

23 Blockaufbau 

40 Fig- 6 zeigt exemplarisch den Aufbau des KontroU- 
Token fur die datagrammortentierten Verfahren 
(D-MC). Dem Header entsprechend dem erfindungsge- 
maBen Verfahren mit Angaben zur Token-Lange, der 
globalen Sequenznummer, der Block-Sequenznummer 

45 des Token und zum Blocktyp (hier: KontroH-Token) fol- 
gen die Kontrollbereiche der einzeinen Ringteilnehmer, 
jeweils mit variabler Lange. Jeder Kontrollbereich um- 
faBt einen teilnehmerbezogenen Header mit der Anga- 
be des Teilnehmers und der KontroUbereichslange und 

50 nachfolgend die Kontrollf elder zu den versendeten 
Nachrichtenblocken dieses TeUnehmers. Jedem iiber- 
tragenen Nachrichtenblock ist ein Kontrollfeld im Kon- 
troll-Token zugeordnei. Ein KontroUfeld besteht a us 
der Angabe des Absenders, der teilnehmerspezifischen 

55 Sequenznummer und der globalen Sequenznummer des 
Nachrichtenblocks. 

Der beispielhafte Aufbau eines Nachrichtenblocks 
nach dem datagrammorientierten Verfahren (D-MC) ist 
in Fig. 7 dargesteUt Dem Block- Header mit der Angabe 

60 der Blocklange, der Kennung des Absenders, der Block- 
Sequenznummer und des Blocktyps (hier: Nachrichten- 
block) folgen die Nachrichten des Absenders. Diese be- 
stehen wiederum aus einem Header und den Daten 
selbst, Der Nachrichten-Header setzt sich zusammen 

65 aus einem Selektor zur Zuordnung von Nachrichten 
und der Angabe der Nachrichtenlange, 

Nicht eingezeichnct sind durch unterlagerte Proto- 
koll- und Netzwerkschichten hinzugefugte Informatio- 
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nen(bei Fragmentierung teilweise mehrfach): Ethernet-, 
IP- und UDP-Header. 

Samtliche Informationseinheiten werden blockorien- 
tiert zwischen den Protokoll-Schichten ausgetauscht 

Init- und Konfigurations-Token beinhalten im Daten- 
teil die System-Statusinformation. Die weiteren asyn- 
chronen Informationseinheiten sind entsprechend dem 
Nachrichtenblock aufgebaut Abhangig vom Typ der 
Informationseinheit steht im Datenbereich die Kennung 
des Absenders bzw. der Datenbereich ist leer, dh.es 
wird nur der Blockheader ubertragea 

3. Bearbeitung von Fehlem/Ausfallen 

Die Fehlertoleranz-Mechanismen zur Erkennung, 
Lokalisierung und Behandlung von Fehlern/Ausfallen 
im System sind bezuglich der SichersteUung der Daten- 
konsistenz sowie eines unterbrechungsfreien Systembe- 
triebs von fundamentaler Bedeutung. Die Kemeigen- 
schaft der beschriebenen Verfahren ist die Obereinstim- 
mung des Tokenstands (Oberwachung) und des Infor- 
mation sstands der einzeinen Teilnehmer. Dies ermdg- 
iicht die exakte Rekonstruktion des Informationsstands 
im Fehlerfall und gewahrleistet die Datenkonsistenz. 

Die MaBnahmen zur Erkennung, Lokalisierung und 
Behandlung von Fehlern (Fehlerverarbeitung) werden 
nachfolgend anhand eines Ausfuhrungsbeispiels erlSu- 
tert; sie sind fur alle drei erfmdungsgemaBen Verfahren 
identisch, 

Es bestehen folgende Anforderungen an die Fehler- 
verarbeitung: 

— Fehler/Ausfalle sind zu erkennen und zu lokali- 
sieren. 

— Ausgefallene Rechner sind auszugliedem, bei 
. Busausfall ist die Obertragung auf dem redundan- 

ten Bus fortzusetzen. 

— Die geSnderte System-Statusinformation ist 
konsistent an alle (intakten) Teilnehiner zu Obertra- 
gen. 

— Der Datenverkehr ist von dem Teilnehmer mit 
dem zuletzt gultigen Daten- bzw. Kontroll-Token 
fortzusetzen. 

— Die Fehlerverarbeitung hat schnell und unter 
Wahrung der Datenkonsistenz zu erfolgen. 

Aufgrund der unbestatigten Obertragung von Infor- 
mation fuhren alle Fehler bzw, Ausfalle im System zu 
einem Verlust des Token. Ein Verlust wird durch Time- 
out erkannt (Token-Timeout). Die Fehlerverarbeitung 
bei erkanntem Token- Verlust gliedert sich in mehrerc 
Phasen: 

— Lin kcheck- Phase, 

— I nit-Token- Phase. 

— Konfigurations-Token-Phase. 

Teilnehmer, die einen Fehler erkannt haben (Token- 
Timeout) prufen den Zustand des Nachfolgers bzw. des 
LAN- Bus, indem zum Nachfolger ein Linkcheck-Re- 
quest ubertragen wird. Dieser wird von intakten Nach- 
folgern mil einem Linkcheck-Acknowledge beantwor- 
tet Bei erfolgreichem Linkcheck wird an den Nachfol- 
ger ein Init-Token verschickt, was diesen auffordert sei- 
nerseits den Nachfolger zu prtifen. Bei nicht erfolgrei- 
chem Unkcheck wird (nach mehrmaligen Versuchen) 
der defekte Nachfolger ausgegliedert. die gcanderte Sy- 
stem-Statusinformation im Init-Token eingetragea Das 
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Init-Token wird in diesem Fall an den Nachfolger des 
ausgegiiederten Teilnehmers ubertragen. Dies gilt bei 
Einfachfehlern im System. Bei Mehrfachfehlern wird 
das Init-Token an den nachsten intakten Teilnehmer im 
5 Ring ubertragea Der Obertragung des Init-Token geht 
grundsatzlich die Linkcheck-Phase voraus. 

Die Init-Token-Phase dient gleichzeitig der Erraitt- 
lung des Ring-Teilnehmers mit dem zuletzt gultigen Da- 
ten- bzw, Kontroll-Token (Ringmaster). Der Ringma- 

10 ster ist kein statisch festgelegter Teilnehmer, er wird im 
Fehlerfall temporSr, d, h. abhangig vom aktuellen Ober- 
tragungsstand ermittelt, Der Ringmaster setzt nach er- 
folgter Fehlerverarbeitung die Obertragung des Daten- 
bzw. Kontroll-Token fort Zur Ermittlung des Ringma- 

15 ster wird das Daten- bzw. Kontroll-Token mit einer 
Sequenznummer versehen, welche von jedem Teilneh- 
mer beim Sendevorgang erhoht wird. Wahrend der Feh- 
lerverarbeitung wird von jedem Teilnehmer beim Ver- 
senden eines Init-Token in diesem die Sequenznummer 

20 des zuletzt versendeten Daten- bzw. Kontroll-Token 
eingetragcn, d. h. jeder Teilnehmer *T>ewirbt" sich als 
mdglicher Ringmaster. Wird ein Init-Token mit kleine- 
rer Sequenznummer als der lokalen Sequenznummer 
des zuletzt versendeten Daten- bzw. Kontroll-Token 

25 empfangen, so wird das empfangene Init-Token verwor- 
fen, es wird ein Init-Token mit der eigenen Sequenz- 
nummer weiter Obertragen. Besitzt ein empfangenes 
Init-Token eine grdQere als die lokale Sequenznummer. 
so wird dieses weiter ubertragen (mit ggf. geanderter 

30 Konfiguration). Als Ergebnis dieses Algorithmus bleibt 
nur das Init-Token des Ringmaster ubrig. Der Ringma- 
ster erkennt sich als solcher durch den volistandigen 
Umlauf seines Init-Token. Im Init-Token des Ringma- 
ster ist nach einem volistandigen Umlauf die aktuelle 

35 System- Konfiguration enthalten (ausgegliederte Teil- 
nehmer sind aus der Liste aktiver Rechner entferni). 
Der Ringmaster ubertrSgt in der nachfolgenden Phase 
diese Konfiguration mit einem Konfigurations-Token 
an die anderen Teilnehmer. Nach erfolgreichem Umlauf 

40 des Konfigurations-Token wird der Datenaustausch 
vom Ringmaster mit dessen Daten- bzw. Kontroll-To- 
ken weitergefuhrt Information eines ausgegiiederten 
Teilnehmers wird vom jeweiligen Vorganger aus dem 
Daten- bzw. Kontroll-Token entfemt. Dies stellt sicher, 

45 daS Nachrichten von alien intakten Teilnehmem emp- 
fangen werden. 

Treten wahrend der Fehlerverarbeitung weitere Feh- 
ler auf, so wird dies Qber einen Token-Timeout erkannt 
Die Fehlerverarbeitung wird neu gestartet Die mehr- 

50 phasige Fehlerverarbeitung mit Init- und Konfigura- 
tions-Token gestattet auch die Tolerierung von Mehr- 
fachfehlern. 

Das oben beschriebene Verfahren zur Bestimmung 
des temporaren Ringmasters ia&t sich in nachstehende 
55 Merkmale gliedem: 

a) ein Teilnehmer, welcher einen Fehler erkannt hat 
(Token-Timeout) verschickt einen Init-Token mit 
der Sequenznummer des zuletzt versendeten Da- 

60 ten- bzw. Kontroll-Token, 

b) ein Teilnehmer, welcher einen Init-Token erhalt, 
versendet einen Init-Token mit einer Sequenznum- 
mer, welche aus dem Maximalwert der Sequenz- 
nummer des zuletzt versendeten Daten-Token und 

65 der Sequenznummer des erhaltenen Init-Token ge- 
bildet wird, 

c) ein Teilnehmer, welcher zuvor einen Init-Token 
versendet hat und einen Init-Token mit einer Se- 
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quenznummer erhalt, welche kleiner ist als die Se- 
quenznummer des zuletzt versendeten Init-Token. 
verwirftden empfangenen Init-Token, 
d) ein Teilnehmer, welcher zuvor einen Init-Token 
versendet hat und einen Init-Token mit einer Se- 5 
quenznummer erhdit, welche identisch ist mit der 
Sequenznummer des zuletzt versendeten Init-To- 
ken (Daten- bzw. Kontroll-Token). erkennt sich als 
Ringmaster, ubertragt die geanderte Systemkonfi- 
guration ringfdrmig an alle Teilnehmer und setzt 10 
anschlieBend die Obertragung mit dem zuletzt gul- 
tigen Daten- bzw. KontrolUToken fort. 



Patentansprache 



15 



1. Vcrfahren zur NachrichtenObertragung nach 
dem Erzeuger/Verbraucher-Prinzip zwischen Teil- 
nehmem in einem verteilten System mit Token- 
Passing und mit ZeitQberwachung zur Stdrungser- 
kennung, dadurch gekennzeldmet, daB zur — 20 
auch im Stdrungsfall — konsistenten Nachrichten- 
ubertragung 

a) entweder eine als Ring-Multicast (R-MC) 
bezeichnete erste Verfahrensvariante verwen- 
det wird, bei der ein Daten-Token ira Ring 25 
gefuhrt wird, das Information enthSlt zur 
Nachrichten-(Nutzdaten-)Obertragung, 
Steuening der Sendeerlaubnis, Sequentialisie- 
rung der Nachrichten-Reihenfolge sowie zur 
gegenseitigen Teilnehmer-Oberwachung, 30 

b) Oder eine als Datagramm-Multicast (D-MC) 
bezeichnete zweite Verfahrensvariante ver- 
wendet wird, bei der ein KontroU-Token im 
Ring gefuhrt wird und Nachrichten (Nutzda- 
ten) im physikalischen Multicast mit Data- 35 
grammen Qbertragen werden, wobei 

bl) im Fall einer zugriffsgesteuerten Nachrich- 
tenUbertragung (D-MC/Z) 

— die Nachrichtenabertragung nur vom je- 
weiligen Teilnehmer mit Kontroll-Token-Be- 40 
sitz erfolgt, und 

— das Kontroll-Token Information enthait zur 
Steuerung der Sendeerlaubnis, zum Austausch 
von Bestatigungs- und Reihenfolgeinforma- 
tion sowie zur gegenseitigen Teilnehmer- 45 
Oberwachung. und 

b2) im Fall einer spontanen Nachrichtenaber- 
tragung(D-MC/S) 

— die Nachrichtenubertragung spontan, unab- 
hangig von der Position des IControil-Tokens 50 
nach einem konkurrierenden Zugriffsverfah- 
ren erfolgt, und 

— das Kontroll-Token Information zum Aus- 
tausch von Bestatigungs- und Reihenfolgein- 
formation sowie zur gegenseitigen Teilneh- 55 
mer-Oberwachung enthalt, und 

c) bei alien Verfahrensvarianten (R-MC, 
D-MC) ein spezielles Token- Verfahren ver- 
wendet wird, das auf der im Obertragungs ver- 
fahren gegebenen Obereinstimmung des eo 
Oberwachungs- und Informationsstands der 
Teilnehmer basiert, und mit dem im Fehlerfall 
ein aus einer fortlaufenden Sequenznummer 
abgeleitetes folgerichtiges Wiederaufsetzen — 
ohne Beeintrachtigung der Datenkonsistenz 65 

— durchgefuhrt wird. 

2. Verfahren nach Anspruch 1. dadurch gekenn- 
zeichnet, daB LAN-basierte standardisierte Kom- 



munikationsprotokolle, wie z. B. TCP/IP, UDP/IP, 
ISO/OSI verwendet werden. 

3. Verfahren nach Anspruch 1 oder 2, dadurch ge- 
kennzeichnet, daB Nachrichten (Nutzdaten) block- 
weise Qbertragen werden. 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daB bei Verwendung des Ring-Multi- 
cast(R-MC)-Verfahrens das Daten-Token Nach- 
richten enthalt 

5. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daB bei Verwendung des Datagramm- 
MuIticast(D-MC/Z oder D-MC/S)-Verfahrens das 
Kontroll-Token einen ersten Kopfteil mit Informa- 
tion gemaB einem LAN- Bus-Standard, einen zwei- 
ten Kopfteil gemaB einem LAN-Protokoll-Stan- 
dard, einen dritten Kopfteil mit Token- und Ken- 
nungs-Information sowie Bestatigungs- und Rei- 
henfolge-Information flbertragener Nachrichten- 
bl5cke enthalt 

6. Verfahren nach Anspruch 5, dadurch gekenn- 
zeichnet, daB jeder Nachrichtenblock (Data- 
gramm) einen ersten Kopfteil mit Information ge- 
m^ einem LAN-Bus-Standard, einen zweiten 
Kopfteil gemaB einem LAN-Protokoll-Standard. 
einen dritten Kopfteil mit Kennungs- Information 
sowie Nachrichten enthalt 

7. Verfahren nach einem der vorstehenden Anspru- 
che, dadurch gekennzeichnet, daB die Nachrichten 
einen Kopfteil mit Selektor zur Nachrichten-Aus- 
wahl und Langenangabe enthalten. an welchen sich 
Nutzdaten anschlieBen. 

8. Verfahren nach einem der vorstehenden Anspru- 
che, dadurch gekennzeichnet, daB bei Stdrungen 
bzw. Aus^len von Teilnehmem selbsttatig eine 
Ausgliederung des fehlerhaften Teihiehmers er- 
folgt 

9. Verfahren nach einem der vorstehenden Anspru- 
che, dadurch gekennzeichnet, daB zur Informa- 
tionsubertragung wahlweise ein Einfach- oder 
Doppelbussystem benutzt wird, wobei im Doppel- 
bussystem im Storungsfall selbsttatig und ohne Be- 
eintrachtigung der Datenkonsistenz eine Umschal- 
tung auf das redundante Bussystem erfolgt 

10. Verfahren nach einem der vorstehenden An- 
spruche, dadurch gekennzeichnet, daB neben der 
Informationsubertragung mit Token bzw. Data- 
grammen zusatzliche asynchrone Nachrichten 
Qbertragen werden zur Integration weiterer Ring- 
teilnehmer, OberprQfung der Funktionstuchtigkeit 
von Teilnehmem und zur Fortsetzung des Netz- 
werkbetriebs nach einer Stoning. 

11. Verfahren nach einem der vorstehenden An- 
sprQche, dadurch gekennzeichnet, daB zum folge- 
richtigen Wiederaufsetzen im Stdrungsfall fur je- 
den Ubertragungszustand eine eindeutige Ken- 
nung benutzt wird, die dadurch gebildet wird. daB 
jedes Daten- bzw, Token-ProtokoU mit einer Se- 
quenznummer versehen wird, welche von jedem 
Teilnehmer beim Sendevorgang erhdht wird. 

12. Verfahren nach einem der vorstehenden An- 
spruche, dadurch gekennzeichnet, daB alle Fehler 
oder Ausfalle im System zum Verlust des Token 
fuhren, der durch eine als Token-Timeout bezeich- 
nete Oberwachung von den Teilnehmem erkannt 
wird, woraufhin nachstehende Verfahrensschritte 
durchgefuhrt werden: 

a) im ersten Schritt prufen Teilnehmer, die ei- 
nen Fehler erkannt haben, den Zustand des 
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Nachfolgers, wobei defekte Teilnehmer ausge- 
gliedert werden, 

b) im zweiten Schritt wird die mogiicherweise 
geanderte System-Konfiguration und ein tem- 
porarer Ringmaster ermittelt, der derjenige 5 
Teilnehmer ist, der vor Auftreten des/der Feh- 
ler im System den zuletzt gultigen Daten- bzw. 
Kontroil-Token gesendet hat, d h. der Teilneh- 
mer mit der hochsten Sequenznummer im Sy- 
stem, und 10 

c) im dritten Schritt Obertragt der Ringmaster 
mit einem Konfigurations-Token die geander- 
te System-Statusinformation in einem Umlauf 
an alle intakten Teilnehmer und setzt nach er- 
folgreich erfolgtem Umlauf die Obertragung 15 
des Daten- bzw. Kontroil-Token fort. 

13. Verfahren nach Anspruch 12. dadurch gekenn- 
zeichnet, daB die Prufung des Zustands des Nach- 
folgers im Schritt a) dadurch erfolgt, daB ein Teil- 
nehmer zum Nachfolger ein Telegramm "link- 20 
check-Request" Obertragt und der 

a) falls dieser intakt ist, von ihm ein Antwortte- 
legramm "Linkcheck-Acknowiedge" erhalt, 
worauf der Teilnehmer ein Aufforderungstele- 
gramm "Init-Token" an den Nachfolger sendet, 25 
das diesen auffordert, seinerseits seinen Nach- 
folger zu prufen, bzw. 

b) falls der Nachfolger defekt ist, dieser - ge- 
gebenenfalls nach raehrmaligen Versuchen 
ausgegliedert wird und in das Telegramm "Init- 30 
Token" die geanderte System-Statusinforma- 
tion an den Nachfolger des ausgegliederten 
Teilnehmers ubertragen wird 

14. Verfahren nach Anspruch 12 und 13. dadurch 
gekennzeichnet, daB im Verfahrensschritt b) gemaB 35 
Anspruch 12 der temporare Ringmaster fur das fol- 
gerichtige Wiederaufsetzen dadurch ermittelt wbd, 
daB 

— ein Teilnehmer, welcher einen Fehler er- 
kannt hat (Token-Timeout) einen Init-Token 40 
mit der Sequenznummer des zuletzt versende- 
ten Daten- bzw. Kontroli-Token verschickt, 

— ein Teilnehmer, welcher einen Init-Token 
erhalt, einen Init-Token mit einer Sequenz- 
nummer versendet, welche aus dem Maximal- 45 
wert der Sequenznummer des zuletzt versen- 
deten Daten-Token und der Sequenznummer 
des erhaltenen Init-Token gebildet wird, 

— ein Teilnehmer. welcher zuvor einen Init- 
Token versendet hat und einen Init-Token mit 50 
einer Sequenznummer erhalt, welche kleiner 
ist als die Sequenznummer des zuletzt versen- 
deien Init-Token, den empfangenen Init-To- 
ken verwirft, 

— ein Teilnehmer, welcher zuvor einen Init- 55 
Token versendet hat und einen Init-Token mit 
einer Sequenznummer erhalt, welche identisch 
ist mit der Sequenznummer des zuletzt versen- 
deten Init-Token (Daten- bzw. Kontroil-To- 
ken), sich als Ringmaster erkennt, die geSnder- 60 
te Systemkonfiguration ringformig an alle 
Teilnehmer Obertragt und anschlieBend die 
Obertragung mit dem zuletzt gultigen Daten- 
bzw. Kontroil-Token fortsetzt, 

15. Verfahren nach einem der Anspruche 12 bis 14, es 
dadurch gekennzeichnet, daB in einem System mit 
redundantem Bus im Verfahrensschritt a) gemaB 
Anspruch 12 die Prufung des Nachfolgers unter 
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abwechselnder Benutzung der beiden Bussysteme 
erfolgt, urn f estzustellen, ob der Fehler in einem der 
Bussysteme oder im Nachfolger liegt 
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